Many enterprises having computer networks want their client computers to be carefully managed by an administrator or the like from a central location. Such centralized management includes deploying applications to the client computers, maintaining and upgrading applications, and removing other applications.
However, before a client computer can be centrally managed, it is necessary to install management software on the client machine. This process is generally referred to as “Client Installation.” When dealing with relatively small networks, it is possible for administrators to personally visit each client computer and install and management software thereon. However, as networks grow, e.g., on the order of many thousands of machines, visiting each machine becomes impractical, if not impossible. Teams of installers have been employed for this purpose, however this has its own drawbacks, including significant expense.
Attempts to automate client installation have heretofore still required considerable manual intervention at the client machine. In the most common form of this manual intervention, each end user is required to log onto the computer system, which causes pre-configured logon scripts to run. The scripts then handle the installation of the management software. As another common alternative, the user may manually connect to a server from the client machine, and execute a batch file or executable program to initiate the installation of client software.
A first problem with this “logon script” method of installing the management software on client computers is that administrators do not have an automated and scalable way to initiate the installation. For example, if an administrator knows of the existence of a group of computers, and wants to install management software agents on those computers, the administrator has to wait for actions to occur on the local machine, i.e., a user logon or user connection to a server and execution of a batch file. The running of logon scripts is rather unpredictable, as some systems, especially servers, rarely have users logging onto them, some systems are not configured to run logon scripts, and some systems have users logged on for extended periods of time before logging off and logging back on again. The manual running of a batch file is also not very desirable, as many users are unable or unwilling to perform this task.
Another drawback to logon script installation is that after the user begins the process of logging onto the machine, the use of logon scripts for the time-consuming task of installing and/or configuring software causes potentially unacceptable delays before a user is able to begin using the computer. Moreover, logon scripts cannot always be hidden from the user during execution, which allows the user to interfere with the execution of the logon script, and/or call for support merely to ask why the script is running. Interfering with the logon script defeats the very purpose of client management, while calls to a support desk to inquire about scripts are expensive and needless.
Moreover, the server is still highly involved in manual installations, which causes other problems, including security and scalability issues. More particularly, for complete installation of management software onto client machines, the servers are configured with a security account having “Administrator” rights of all client machines. This presents a security concern, because access to such an account allows remote access to virtually all aspects of all client machines. Also, to configure the client machines, the ratio of servers to client machines can be one-to-a thousand or more, and the work performed by the server can only be done to a very small number of clients at a time. A bottleneck often results from this scalability problem.